Method and System for tracing individual Transactions at the Granularity Level of Method Calls Throughout Distributed Heterogeneous Applications without Source Code Modifications Including the Detection of Outgoing Requests

ABSTRACT

A monitoring system uses existing tracing data describing individual distributed transactions to determine if a recorded thread communication performed by the monitored transactions is internal to a monitored application or whether the recorded thread communication is an outgoing communication. Thread communications which are sent and received by threads that are monitored by the monitoring system are considered to be internal communications. Thread communications for which only the sending thread is monitored are considered to be outgoing communications. The determination process analyzes client side tracing data of the recorded thread communication and determines whether corresponding server side tracing data is available. If no corresponding server side tracing data is available, the thread communication is considered to be an outgoing communications. Examples of thread communications include HTTP requests, web service calls, and remote method invocations.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a:

-   -   continuation-in-part of co-pending U.S. patent application Ser.         No. 12/191,409, filed on Aug. 14, 2008, Attorney Docket Number         D0004-1004, which claims priority from U.S. Prov. Pat. App. Ser.         No. 60/955,654, filed on Aug. 14, 2007;     -   continuation-in-part of co-pending U.S. patent application Ser.         No. 12/971,408, filed on Dec. 17, 2010, Attorney Docket Number         D0004-1006, which claims priority from U.S. Prov. Pat. App. Ser.         No. 61/287,610, filed on Dec. 17, 2009, Attorney Docket No.         D0004-1006L.         This application incorporates by reference all of the patent         applications listed above.

BACKGROUND

Object oriented and bytecode based software development platforms, including the SUN MICROSYSTEMS® JAVA™ platform and the MICROSOFT®.NET platform, have gained wide acceptance for developing Internet and Enterprise class software applications. Bytecode based software provides cross-platform and cross-language compatibility and eases the networked integration of software applications.

Remote method invocation available for the platforms, like SUN MICROSYSTEMS® Remote Method Invocation (RMI) and the MICROSOFT®.NET Remoting system, and messaging services like the SUN MICROSYSTEMS® JAVA™ Messaging Service (JMS) or the MICROSOFT® Messaging Queue ease the creation of distributed and loosely coupled architectures.

Approaches like service oriented architecture (SOA) use this features to provide flexible application architectures which can be adapted to rapidly changing market demands.

Albeit, this flexibility eases building and updating the functionality of applications, it constitutes a challenge for conventional performance monitoring and tracing tools which traditionally consider the scope of an isolated application. Most existing tools are not prepared to trace transactions over the borders of threads or different virtual machines.

Following the execution path of a transaction over the borders of threads, processes or different host systems is essential for tracing complete end-to-end transactions, which may be processed by a chain of different application servers that may communicate in various ways.

Information that depicts the different processing stages on different application servers and provides specific performance information for the processing stages is a precondition for performance analysis of distributed applications. To provide such information, it is required to correlate isolated trace information acquired from the different servers participating in a transaction, to depict a consistent end-to-end transaction.

There are some systems available that provide mechanisms for tracing distributed transactions, but those systems either depend on specific properties of the monitored system, like e.g. synchronized clocks of servers involved in distributed transactions or generate insufficient correlation information. The generated correlation information is sufficient to reconstruct parent-child relationships between parts of distributed transaction executed on different servers, but they fail to reconstruct the exact sequence in which child parts of the transactions were activated. Other systems only provide post-mortem analysis of transactions, or are not able to analyze blocked or stalled transactions.

Some of the existing monitoring systems have memory requirements which are depending on the nesting depth of executed methods, which makes a prediction of the memory overhead caused by the monitoring system impossible, and which may cause a crash of the monitored system in case of deep nested method executions which may e.g. occur in recursive methods.

JaViz[2], is a monitoring system developed by IBM which allows tracing of distributed transactions running on JAVA™ platforms, using the SUN MICROSYSTEMS® RMI framework for communication. The system amends the used virtual machines in a way that they generate tracing data for each executed method, which is written to trace files. The trace files contain statistical information about local method calls, outbound remote method calls and inbound remote method service requests. The trace files also contain correlation data which enables to match outbound remote method calls invoked on one virtual machine with the corresponding inbound remote method service request received on another virtual machine. After a distributed transaction is terminated, a merging tool is executed, which evaluates the correlation data stored in the trace files generated by the involved virtual machines. The merging tool generates an overall trace file which describes the whole distributed transaction. The so generated trace file is interpreted by a visualization tool which provides a tree-like view of the transaction. Although JaViz provides useful information for analyzing distributed transactions, the restriction to post-mortem analysis and the relatively complex handling of the different trace files exclude this approach from usage in production environments.

The Application Response Measurement framework (ARM) [2], a standard for monitoring application performance, created by Hewlett-Packard and Tivoli WebSites, provides infrastructure for real-time monitoring of distributed transactions. To trace transactions with ARM, calls to ARM methods are inserted at the entry points and all exit points of methods which should be monitored. This requires access to the source code of the application which should be monitored and the ability to rebuild the application after ARM monitoring is included. Accessing the application source is often difficult or even impossible. Additionally the requirement to adapt application source code and rebuild the application to apply changes of the set of monitored methods makes this approach inflexible in terms of adapting the monitoring configuration.

The system described in [3] and [4] combines the ARM framework with bytecode instrumentation, and thus removes the requirement to adapt the application source code to install monitoring code. The described system creates a stack data structure at the thread local storage which maps the current method call stack. The stack data structure is used to correlate method calls to the method execution sequence performed in the local thread of the instrumented methods and can become a severe problem if the level of the nesting becomes high or unpredictable, as it is e.g. possible in recursive method calls. The system places instrumentation code at entries and exits of monitored methods. Entry instrumentations create and initialize a record for storing performance data, and exit instrumentations update the record and send it to an instance which analyzes and visualizes the record. This approach keeps network traffic low because only one data record is sent for each monitored method call, but it causes problems in handling blocked or stalled transactions. In case of a blocked or stalled transaction, in the worst case no method is exited and thus no monitoring data of the blocked transaction is generated. If a monitored method activates another thread, either via explicit thread switch, or by invoking a remote method, the system generates correlation information which identifies the activating method, the thread that executes it and the server which is hosting the virtual machine. The correlation information is transferred to the activated thread and allows correlating the activated thread with the activating instrumented method, but in case of multiple thread activations performed by one monitored method, the provided correlation information is not sufficient to reconstruct the sequence of the multiple thread activations. Knowing the sequence of the activations would be very useful to analyze problems caused by race conditions between the activated threads.

The system described in [5] provides tracing mechanisms which can be dynamically enabled and disabled. The system uses bytecode instrumentation to place entry interceptors and internal interceptors in the monitored application. If a transaction invokes an entry interceptor, the entry interceptor first evaluates a set of rules to decide if evaluation. An interceptor consists of monitoring code placed at the entry and at each exit of instrumented methods. Interceptors produce and send measurement data when executing the code placed at method exits. This leads to problems with blocked transactions, as described before. The system allows tracing transactions which span multiple servers, but it uses timestamp information for correlation, and thus requires synchronized clocks at the involved servers, which is a requirement that is often hard to fulfill.

The system described in [6] also aims to trace distributed transactions, but as the approaches discussed before, it does not address blocked transactions. Additionally, it uses timestamp data for correlation and thus requires synchronized clocks.

Consequently, there is a need for a monitoring system that allows tracing of distributed end-to-end transactions, which overcomes the shortcomings of currently existing approaches.

Additionally, visibility of resources used by the transaction is required, like e.g. heap memory allocations for creation of new objects, performed during transaction execution, or time spent to synchronize with other, concurrent transactions.

Another important missing feature is the ability to distinguish time the transaction actually spent executing, and time the transaction was suspended due to execution maintenance tasks of the underlying virtual machine, like running garbage collector or re-compiling byte-code.

-   -   [1] Kazi et al., “JaViz: A client/server Java profiling tool”,         IBM SYSTEMS JOURNAL, VOL 39, NO 1,2000     -   [2] “Monitoring and Diagnosing Applications with ARM 4.0”,         http://www.opengroup.org/tech/management/arm, 2004     -   [3] Rees et al., “Synthesizing Application Response Measurement         (ARM) Instrumentation, Hewlett-Packard, US2005/0039172 A1     -   [4] Avakian et al., “Using Interceptors and Out-of-Band Data to         monitor the Performance of Java 2 Enterprise Edition (J2EE)         Applications”, Hewlett-Packard, US2005/0039171 A1     -   [5] Fung et al., “Method for Tracing Application Execution Path         in a Distributed Data Processing System”, Poon Fung, Cupertino,         Calif. (US), US200717194664 B1     -   [6] Maccabee et al., “Application End-to-End Response Time         Measurement and Decomposition”, International Business Machines         Corporation, US2000/6108700

SUMMARY

Some embodiments of the disclosed invention create tracing data describing individual distributed transactions executed by a monitored application, where the tracing data enables the identification of thread communications that are performed by those distributed transactions and which are directed to receivers outside of the monitored application.

A “thread communication” is defined herein as an activity, performed by a sender thread, that triggers creation and/or activity of a receiver thread. More specifically, the activity of the sender thread may include the execution of a specific thread communication method that creates and sends a thread communication message, and the activity of the receiver thread may include receiving and processing the received message in a communication service method. The receiver thread may, for example, be executed by another virtual machine or process than the sender thread, which may be located on another host computer than the receiver thread. To perform the thread communication, the sender thread may send a thread communication message to the receiver thread. Such thread communications may, e.g., include HTTP communications (e.g., requests and/or responses), web service communications (e.g., requests and/or responses), and remote method invocation-based thread communication.

One or more monitoring systems may be used to monitor one or more applications (referred to herein as “monitored applications”) and thereby to produce tracing data for the monitored transactions. In some cases, a single monitoring system may monitor both a sender thread and the receiver thread that receives a thread communication from the sender thread. In other cases, a first monitoring system may monitor the sender thread, while a second monitoring system monitors the corresponding receiver thread.

Tracing data produced by embodiments of the present invention may be used to determine if: (1) a thread communication executed by a monitored transaction (e.g., in the form of a HTTP request or a remote method invocation) was received by a receiver thread monitored by the same monitoring system as the sender thread (referred to herein as an “internal communication”); or (2) if the receiver thread is not monitored or is monitored by a different monitoring system than the monitoring system that is monitoring the sender thread (referred to herein as an “outgoing communication”). Other examples of internal or outgoing thread communication types include the invocation of web services and sending and receiving messages using messaging servers.

The term “thread communication message” is an abstraction for messages sent from a client thread to a server thread to perform a thread communication. Similarly, the term “communication service method” is an abstraction for service methods handling incoming thread communication requests at the server side. Examples of thread communication messages are HTTP requests or remote method call messages. HTTP service methods or remote method handling methods are examples of communication service methods.

Variants of those embodiments may also capture data describing the destination of executed thread communications on the client side, like a HTTP URL for HTTP requests or web service requests, or a remote method server name for a remote method invocation. This data may be used to additionally describe detected outgoing thread communications.

Additionally, data describing the success state of monitored thread communications may be captured, such as a HTTP status code for HTTP or web service requests.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1: conceptually depicts the process of instrumenting selected methods of monitored applications with sensors, and shows extraction and storage of sensor context information.

FIG. 2: shows a sensor context node which may be used to store contextual information concerning a specific instrumented sensor.

FIG. 3: illustrates a portion of a monitored transaction where one thread activates another thread running within the same virtual machine. The transfer of correlation information between threads and sending of path events is shown.

FIG. 4: depicts a portion of a monitored transaction where one thread invokes a remote method, which may be executed by a different virtual machine, running on different host systems, connected by a computer network. It also shows the transfer of correlation information within the network message representing the remote method invocation.

FIG. 5: depicts a monitored transaction that sends a message using a dedicated messaging infrastructure like a messaging server to one or more recipients, including the and sent to multiple recipients, also the attached correlation information is multiplied.

FIG. 6: conceptually shows a parent information data structure which may be used to transfer correlation information between different threads. The threads may run in different virtual machines, which may in turn run on different hosts, which are connected by a computer network.

FIG. 7: depicts a tag information data structure which may be used to store information to correlate a chain of distinct method calls within one thread.

FIG. 8: shows different forms of event nodes which are used to notify the correlation engine about events that occurred within monitored applications. More specific, it conceptually depicts a start path event node, which may be used to indicate the start of a transaction, a path event node which may indicate the entry or exit of a monitored method, a path correlation node, which may be used to indicate a thread switch within a monitored transaction, an allocation event node which may indicate heap memory allocation for creation of new objects performed during transaction execution, a synchronization event node, which may be used to indicate time spent to synchronize the transaction with other concurrent transactions and a runtime suspension event node, which may be used to indicate runtime suspensions that occurred during execution of the transaction.

FIG. 9: describes the process of transferring correlation information between two different threads, being part of a monitored transaction.

FIG. 9 a: conceptually shows the actions performed within the thread that initiates the thread switch.

FIG. 9 b: shows the process of extracting the transferred correlation information in the activated thread;

FIG. 10: shows the transfer of correlation information between a client thread that invokes a remote method and a server thread that executes the invoked method. Both threads may be executed on different host systems which are connected by a computer network.

FIG. 10 a shows the transfer of correlation information to the network message representing the remote method invocation.

FIG. 10 b: depicts how the correlation information is transferred to the local storage of the thread serving the remote method call.

FIG. 11: depicts the process of transferring correlation information within messages sent via dedicated messaging services, like messaging server.

FIG. 11 a: shows how the sending thread adds correlation information to a message before it is sent;

FIG. 11 b: depicts the extraction of the correlation information by the thread that receives the message.

FIG. 12: conceptually depicts the execution of a method entry sensor. The entry sensor first checks if the tag info node stored in the thread local storage indicates if a the first within the current thread and sends path events nodes accordingly.

FIG. 13: shows the execution of a method exit sensor. The exit sensor first checks if the tag info node stored in the thread local storage indicates that at least one entry sensor was executed within the current thread. In this case, an event indicating a method exit is sent.

FIG. 14: depicts data structures of path nodes correlation nodes which may be used to represent parts of individual transaction. More specific, it depicts a start path node, which represents a part of a transaction executed within one thread. A path node represents an individual execution of a method, and a path correlation node is used to link the parts of one transaction executed within different threads into a complete end-to-end transaction, spanning multiple threads, virtual machines or host machines. An allocation path node, which may represent heap memory allocations for creation of new objects performed during path execution, a synchronization path node which may indicate time spent to synchronize the transaction with other concurrent transactions and a runtime suspension path node which may represent suspensions of the underlying virtual machine which may have occurred during execution of the transaction.

FIG. 15: shows the processing of a received start path event by the correlation engine.

FIG. 16: shows the processing of a received path correlation event by the correlation engine.

FIG. 17: shows the processing of a received path event by the correlation engine.

FIG. 18: illustrates a portion of a monitored transaction where an allocation method, which performs memory allocations for creation of new objects is executed by an instrumented method.

FIG. 19: illustrates a portion of a monitored transaction where a synchronization method, which may perform synchronization with other, concurrent transactions, is executed by an instrumented method.

FIG. 20: exemplarily depicts runtime suspension notification mechanisms, as provided by debugging/monitoring interfaces of virtual machines, like the JVMTI interface provided by the Sun JAVA™ Virtual Machine, and an event handler which transforms suspension notifications in appropriate path event nodes.

FIG. 21: shows the process of executing an allocation entry and an allocation exit sensor.

FIG. 22: describes the execution of the entry and exit parts of a synchronization sensor.

FIG. 23: illustrates the process of handling an incoming runtime suspension notification by the VM suspension notification handler.

FIG. 24: depicts the process of correlating allocation events to the execution path of a monitored transaction.

FIG. 25: illustrates the process of correlating synchronization events to the execution path of a monitored transaction.

FIG. 26: illustrates the process of correlating runtime suspension events to the execution path of one or a set of monitored transactions.

FIG. 27: shows a monitored system containing a client and a server application which is executing a monitored distributed transaction. The monitored transaction is started at the client application and continues on the server application using a thread communication message sent from the client application to the server application.

FIG. 28: depicts tracing data gathered from the monitored distributed transaction executed by the system described in FIG. 27. The generated tracing data may be used to determine that the thread communication initialized by the part of the monitored transaction executed on the client application was received and handled by a server application which is monitored by the same monitoring system as the client application. This information may be used to tag the recorded thread communication performed by the monitored transaction as an internal communication.

FIG. 29: provides an overview of a monitored application containing a client application which communicates with an external, unmonitored server application via a thread communication message.

FIG. 30: shows tracing data of a monitored distributed transaction executed by the system described in FIG. 29. The generated tracing data shows a thread communication initialized by the monitored transaction on the client application, but it does not contain tracing data describing the receiving and handling of the performed thread communication on the server side. This information may be used to tag the recorded initialization of an thread communication as an outgoing communication.

FIG. 31: shows the process of analyzing tracing data of monitored distributed transactions to detect and visualize outgoing thread communication.

FIG. 32: provides an exemplary visualization of tracing data of a transaction performing an internal thread communication and corresponding visualization of the internal thread communication.

FIG. 33: provides an exemplary visualization of tracing data of a transaction performing an outgoing thread communication and corresponding visualization of the outgoing thread communication.

FIG. 34: shows an exemplary visualization of a transaction performing internal and outgoing the thread communications, and a list based visualization of incoming, internal and outgoing thread communications performed by the transaction.

DETAILED DESCRIPTION

Embodiments of the present invention include a system and method for tracing distributed transactions through heterogeneous application environments, without the requirement to modify application source code. Embodiments of the invention use correlation information which identifies an individual transaction, and the involved servers executing the transaction. The correlation information is transferred to spawned child transactions. Measurement data generated by those child transactions is tagged with the correlation information to enable real-time correlation of distributed transactions at the granularity level of method invocations.

The present invention requires neither source code modifications of monitored source code nor access to the source code to instrument bytecode based software applications. The code of monitored applications is instrumented on the fly, at application run-time, during or after loading bytecode. Neither the deployment of additional libraries to the monitored applications, nor modification or exchange of existing application libraries is required.

The invention discloses a system and method that enables tracing of individual distributed transactions across thread, process or server boundaries at the granularity level of individual method invocations.

The disclosed system and method enables to trace individual transactions that span multiple processes or servers, using remote method invocation frameworks for communication. Additionally, it enables tracing of individual transactions using messaging services for communication, taking also possible multiple message receivers into account.

The disclosed system and method stores correlation information required to correlate method invocations and parts of a distributed transaction in a way that memory required for storing the correlation information is independent of nesting level of method invocations or sub transactions. The constant memory requirement of the correlation information makes memory consumption caused by the monitoring tool more predictable and is especially useful for tracing transactions containing recursive method calls.

In case of blocked transactions, the present invention enables exact real-time determination of the method that caused the blocking of the transaction and the server at which the blocking method is executed.

The present invention allows exact correlation of local and remote sub transactions spawned by a transaction at method invocation level, including also the sequence of multiple sub transactions spawned during the execution of one instrumented method.

The present system and method provides correct tracing and monitoring data of distributed transactions if only a subset of the application servers involved in the execution of a transaction are instrumented. If one or more application servers within the execution chain of a transaction are not instrumented, correct tracing data is provided up to the first not instrumented server.

Present invention enables the reconstruction of the temporal sequence of method invocations being part of a distributed transaction which are executed on different servers, without the requirement of synchronized times at involved servers.

All calculations regarding acquired measurement data and correlation of parts of distributed transaction or method invocations are performed outside of the monitored applications to reduce monitoring caused overhead within the applications.

An agent is deployed to the monitored applications on startup, which monitors and intercepts loading of bytecode by the virtual machine. The agent captures the bytecode and sends it to a remote instrumentation server for instrumentation.

The instrumentation server extracts meta-data from the received bytecode, including, but not limited to the name of the class represented by the bytecode and names of the methods of the class. The instrumentation server determines, according to the extracted meta-data, which may also involve the evaluation of rule sets, which methods should be augmented with instrumentation bytecode. Instances of the instrumentation bytecode are further called sensors.

A sensor indicating the entry and a sensor indicating the exit of an instrumented method are placed, which are further called entry sensors and exit sensors. Entry sensors are placed at the beginning of an instrumented method and exit sensors are inserted at every exit point of an instrumented method.

Instrumented methods may be exited on a normal way, e.g. by the execution of a return statement, or through exception which occurred during method execution and which is not handled within the method. Both exit types are fundamentally different, are handled differently by different instrumentation code, like an enclosing try-catch block to capture exceptions, as known in the art. For the demonstration of the functionality of present invention, a distinction between the method exit types is not relevant and is thus omitted. The exit sensors of the exemplary embodiment described here are handling both kinds of method exits.

Entry and exit sensors use the storage of the local thread to store and retrieve information required to correlate separate method invocations within a single thread.

Additional sensors are placed in methods starting threads, initiating remote method calls or methods sending messages using messaging infrastructure like a messaging server. Those sensors are further called tagging sensors. Tagging sensors extract information required to identify a parent thread which e.g. starts another thread, invokes a remote method or sends a message. The extracted information is used to correlate measurement data from the parent thread with measurement data from dependent threads. The tagging sensors store the extracted information in a place which is accessible for both, the parent thread and the thread or threads invoked by the parent thread.

In case of a thread directly invoked by the parent thread, the extracted information is stored in an object representing the invoked thread. In a Java environment, the extracted correlation information is stored in an additional field to classes implementing the “java.lang.Runnable” interface which was inserted by the instrumentation engine via bytecode manipulation.

For remote method invocations, the tagging sensor stores the extracted correlation in an additional header field of the message representing the remote method invocation.

In case of a sent message, the tagging sensor adds a new parameter to the message and stores correlation information as value of the new parameter.

Although the implementation of tagging sensors for different target technologies, like local thread switches or remote method invocation differs, their basic functionality, consisting of the extraction of correlation information from a parent thread and storing it on a location which is accessible by a thread invoked by the parent thread, remains the same. As a differentiation of tagging sensors according to their addressed target technology is not relevant for the understanding of the present invention, such a differentiation is omitted and tagging sensors are referred to as tagging sensors, regardless of the addressed target technology.

Methods that directly or indirectly activate a thread are instrumented with a tag extraction sensor. Example for those methods are methods that process an incoming remote method invocation, methods that receive a message from a messaging server or a method that is invoked to execute a thread, like the e.g. method “run” of classes derived from the class “java.lang.Thread” for Java environments. The tag extraction sensors retrieve the correlation information stored by the associated tagging sensor and store it in the storage of the local thread to make it accessible for entry and exit sensors.

The implementation of tag extraction sensors also differs between different target technologies, but differentiation between those implementations is not relevant for the understanding of the invention. Thus, as for tagging sensors, different implementations of tag extraction sensors are not differentiated.

On the execution of an entry sensor, the sensor first determines if the current invocation is the first invocation of an entry sensor within current thread execution by using information retrieved from storage of current thread. If the current invocation is the first of an entry sensor within the thread, the sensor also checks if information of a parent transaction, as transferred and initialized by tagging sensors and tag extraction sensors is available in thread storage and sends an event indicating a new started transaction. The entry sensor updates the data in the thread storage to indicate that an invocation of an entry sensor has occurred. Indicators for call depth and the index of spawned child transactions, stored in the current thread storage are reset. Afterwards, an event node, indicating a new started transaction is initialized and sent to a remote correlation engine. The sent event node also contains the information to identify and correlate a parent transaction if information about the parent transaction is available in the thread local storage.

Additionally, measurement data is acquired and an event node indicating a method entry is initialized with the measurement data and sent to a remote correlation engine, and the call depth indicator is incremented.

On execution of an exit sensor, measurement data is acquired and stored in an event node indicating a method exit which is sent to a remote correlation engine. Finally the call depth indicator is decremented.

A remote correlation engine receives the events generated by entry and exit sensors and uses data extracted from the events to incrementally build data structures that reflect the execution of individual, distributed transactions. Concurrently to event correlation and building the data structure representing the transactions, an analysis module accesses the data structure to enable analysis and visualization of transaction in real-time, during the execution of the transactions.

Splitting and independently sending and correlation of method entry and exit events allow the analysis of transactions that block during execution and do not return. The received entry events allow the determination of the last method entered by the transaction, which is also the blocking method. This information is important to isolate and find the root cause for the block.

The described embodiment provides a system and method that allows tracing individual distributed end-to-end transactions. The execution of the traced transactions may involve multiple threads, virtual machines and host systems. The described embodiment allows tracing communication performed by the distributed transactions over multiple channels. The tracing mechanisms described covers communication via sending of messages using messaging services like Sun Microsystems' JMS or Microsoft's Messaging Queue, invoking remote messages, or explicitly activating threads, but the described invention is independent of the underlying communication mechanism and may also be applied to other mechanisms, like Web Service calls. One prerequisite for a successful application of the present invention is that the communication mechanism allows adding correlation information to sent messages as out-of-band information.

The present invention generates correlation information which allows reconstructing the chronological execution sequence of parts of distributed transactions executed on different hosts, even if the clocks of the hosts are not synchronized.

Referring now to FIG. 1, therein a monitored application 101 is shown which is running within a virtual machine 102. An agent 103 is injected into the virtual machine 102, which intercepts the loading of original bytecode 106, performed by the native loader 105, and captures the original bytecode 106. Each agent 103 is provided with a unique agentId 104, which is added to messages sent by the agent 103 and thus allows distinguishing messages received from different agents 103.

The captured bytecode 106 is sent to an instrumentation engine 108. The captured bytecode may be sent via a computer network 118. The instrumentation engine 108 extracts meta-data from the received original bytecode 106. The meta-data is used to identify and select the parts of the original bytecode which are augmented with sensor code. The bytecode parts include of but are not limited to class definitions, method definitions and constant pools. The selection of the bytecode parts may be based on explicitly specified method and class names, identifying single methods or classes, or it may use a rule based system where one rule may match multiple classes or methods. Sensor code is placed in the selected parts of the original bytecode 106 and the instrumented bytecode 107 is sent back to the agent 103 which forwards the instrumented bytecode 107 to the bytecode loading process of the virtual machine 102 which loads the instrumented bytecode 107 instead of the original bytecode 106. Sending the instrumented bytecode 107 may be performed via a computer network 118.

The instrumentation engine instruments 108 methods which should be monitored 110 with entry sensors 111 to detect invocations of monitored methods and exit sensors 112, which detect when execution of monitored methods is finished. Exit sensors detect both normal method exits and exits caused by an unhandled exception. It should be noted that a distinction between both exit types is necessary for a monitoring system to provide correct monitoring information. But this distinction does not foster the understanding of the present information and is thus omitted here.

The instrumentation engine 108 also places tagging sensors 114 in methods initiating an interaction with other threads or virtual machines, like methods sending synchronous or asynchronous messages using messaging oriented middleware, methods preparing network messages representing remote message invocations, or methods initiating an interaction with another thread within the same virtual machine. Those tagging sensors 114 extract correlation information from the thread local storage, which is created by entry sensors 111 and store it in a place where it is accessible for the target threads. Placement of tagging sensors 114 may also include insertion of additional member variables via bytecode manipulation to store the extracted correlation information.

Additionally, tag extraction sensors 116 are placed in methods that receive interactions from other threads, like methods receiving synchronous or asynchronous messages, methods receiving messages representing remote method invocations or methods starting a new thread. Those methods are subsumed here as thread activation methods 115. Tag extraction sensors 116 build the counterpart to tagging sensors 114. The tag extraction sensors store received correlation information within the thread local storage, where it is accessible for other sensors 111.

Allocation methods 119, which like the method “new” which creates a new object of a specific type, or the methods “readObject” or “readSerialData”, which receive serialized input data and create new objects which are initialized with the serialized data, are instrumented with an allocation entry sensor 120 and an allocation exit sensor 121.

Synchronization methods 122, which may be synchronized blocks, methods like “wait”, “join”, etc. which temporarily suspend execution of a transaction, to e.g. synchronize a transaction with other concurrent transactions, are instrumented with a synchronization entry sensor 123 and synchronization exit sensor 124.

The instrumentation engine incrementally builds a sensor context repository 109, which includes context data related to the placed sensors. The context data is retrieved form meta-data extracted from the received original bytecode 106 and may include but is not limited to the name of the class and method where the sensor is placed. Each sensor context data entry may be tagged with a unique sensorId. Placed sensors send this sensorId with every message, which allows correlating measurement data received with the messages with the context of the related sensor, without including context information in each sent message.

FIG. 2 shows a sensor context node 201, which is used to store context information related to a placed sensor. The sensorId 202 may uniquely identify the sensor that is related to the context information stored in a sensor context node 201.

Additionally, a sensor metadata node provides sensor metadata 203 which includes but is not limited to a sensor type, identifying the type of the sensor which may e.g. be a timing sensor type, measuring execution times or a counting sensor type, counting the executions of a method or suchlike; the name of the class which contains the sensor; the name of the method the sensor is injected to; the signature of the method; and the line number of the source code where the sensor is placed.

Referring to FIG. 3, showing a parent thread 301 which is interacting with a child thread 302. The information required to correlate individual method invocations within one thread to a call stack, is stored in the local storage of the threads, within a tag info node 801.

The parent thread 301 enters an instrumented method 110, and the entry sensor 111 of the instrumented method 110 is executed. A start path event node 801 is sent to the agent 103 if the execution of the instrumented method starts a new execution path and a path event node 831 is sent afterwards, regardless if a new execution path is started or not. The agent 103 in turn sends the event node to a correlation engine 307, which may be performed using a computer network 118. If execution of the instrumented method 110 invokes a method that performs a thread switch 303, the tagging sensor 114 of the method is executed. The tagging sensor 114 extracts correlation information required to identify the parent thread 301 and stores it in a parent info node 601 which is attached to the object representing the child thread 302 within the parent thread 301. The object representing the child thread, which may be a “java.lang.Thread” object in Java environments, is also accessible at the child thread 302. Additionally, the tagging sensor sends a path correlation event node 841, which allows the correlation engine 307 to correlate the execution of the child thread 302 with the execution of the instruction within the parent thread 301 that started the child thread 302. On exiting an instrumented method 110, the exit sensor 112 of the method is invoked which sends a path event node 831 indicating a method exit to the agent 103.

On activating the child thread 302, the tag extraction sensor 116 is executed. The tag extraction sensor 116 reads the parent info node 601 stored in the object representing the child thread, creates a tag info node 701 and stores data extracted from the parent info node in the tag info node 701. The tag info node is stored in the thread local storage of the child thread 302.

During the first execution of an instrumented method 110 in the context of the child thread 302, the entry sensor 111 of the instrumented method stores information required to identify the child thread 302 to the tag info node 701 stored in the local storage of the child thread 302. Afterwards it reads the information identifying the parent thread 301 from the tag info node 701 and sends a start path event node 801 which includes information to identify both the parent thread 301 and the child thread 302. Subsequent executions of entry sensors 111 and exit sensors 112 may only send information to identify the child thread 302.

The start path event nodes 801, path event 831 nodes and path correlation nodes 841 are received by a remote correlation engine 307 which transforms the received event nodes into path nodes and incrementally builds representations of the execution paths described by the received event nodes. Transfer of the event nodes may be performed via a computer network 118. The execution path representations are stored in a path repository 308, which may concurrently be accessed by an analysis module 309 to evaluate the available execution path representations and which may also present the analyzed execution paths to the user. The analysis module also accesses the sensor context repository 109 for context information of the sensors that created the event nodes which were used to build the execution paths.

Referring now to FIG. 4, showing a fragment of a transaction that employs remote method invocations. A thread 402 of a client application 401 invokes a remote method which is executed at a server application 406, which may run on a different host connected by a computer network 118. Calling the remote method on the client side 403 invokes a tagging sensor 114 which extracts information including information required to identify the client application 401 and the current thread 402. The extracted information includes but is not limited to a local pathId 703, identifying the current path and an agentId 104, identifying the agent 103 deployed to the application. As there may be only one agent deployed to each application, the agentId 104 also identifies the client application 401. The tagging sensor stores the information in a parent info node 601 which is attached to the message representing the remote method invocation 404. The tagging sensor additionally sends a path correlation event node 841 to the agent which allows determining the sequence of multiple remote method invocations within the body of one instrumented method 110. The message representing the remote method invocation 404 is sent to the server application 405, which may be performed using a computer network 118.

The server application 405 receives the remote method invocation message 404 and executes a remote method service routine 407 to handle the remote method invocation request. A tag extraction sensor 116, instrumented into the service routine extracts the parent info node 601 from the received message and stores the contained information in the tag info node 701 of the current thread 407.

The execution of entry sensors 111 and exit sensors 112 and the handling of different path events are performed as explained in the description of FIG. 3. It should be noted that path events sent from the client application 401 are tagged with the agentId 104 of the client application's agent 103 and path event sent from the server application 405 includes the agentId 104 of the server application's agent 103.

The transfer of parent info nodes 601 along with remote method invocation messages 404 may take the implementation specific characteristics of the underlying remote method invocation protocols into account, but the principle of adding parent info nodes to remote method invocations as out-of-band information remains the same for most protocols.

An exemplary embodiment of the current invention used to trace distributed transactions which involve sending and receiving of messages, using dedicated messaging service infrastructure is depicted in FIG. 5. Current messaging servers provide various methods to transfer messages, including direct sending from one sender to one receiver, or publish-subscribe mechanisms where a publisher adds a message to a topic and multiple subscribers of the topic receive the published message. All those transfer methods may based on sending message objects from one message sender to one or multiple message receivers. Thus it is sufficient to insert correlation information as out-of-band information into the message objects to allow correlation of distributed transactions involving message based communication.

If a method that sends a message 503 via a dedicated messaging server 505 is called, the tagging sensor 114 which is instrumented into the method is executed. The tagging sensor stores correlation information in a parent info node 601 which was extracted from the local tag info 701. The parent info node 601 is attached to the message object 504 before it is sent to the messaging server 505. The message may be sent via a computer network 118. Messaging systems like Sun Microsystems' JMS provide interfaces to add user specific parameters to message objects, which can be used to attach the parent info node 601 to the message object 504.

The messaging server 505 clones the original message 504 and sends those cloned messages 507 to all registered receivers 506, which may be performed using a computer network 118. The receiving applications 506 are notified about the incoming message and methods to receive the message 116 are called. A tag extraction sensor 116 is instrumented to those methods which reads the correlation information of the parent info node 601 from the received message 507 and stores it in the tag info node 701 of the current thread.

The execution of entry sensors 111 and exit sensors 112 and the handling of different path events are performed as explained in the description of FIG. 3. It should be noted that path events sent from the sender application 501 are tagged with the agentId 104 of the sender application's agent 103 and path event sent from the receiver applications 506 contain the agentId 104 of the agents 103 deployed to the receiver applications 506.

FIG. 6 shows a parent info node 601 which is used to transfer correlation information between connected parts of a transaction running in different threads, which may be executed on different hosts, connected by a computer network 118. Information stored in a parent info node contains, but is not limited to an agentId 602, a local pathId 603 and a forkId 604. The agentId 602 of a path info node is initialized with the agentId 104 of the agent 103 which is deployed to the application that generated the parent info node, and uniquely identifies the application that generated the parent info node. The local pathId 603 uniquely identifies the execution of a thread that involved the execution of another thread. The forkId 604 identifies each individual interaction initiated by the thread with other threads, which may be performed by explicitly activating other threads, via remote method invocations, sending of messages or other inter-thread communication mechanisms. The forkId may be incremented each time a thread interacts with another thread.

FIG. 7 depicts a tag info node 701, which is stored in the local storage of a thread. A tag info node 701 stores information required to correlate method calls executed within the local thread in the local data section 720 and information to correlate the local thread with its parent thread in the parent data section 710. The local data 720 section includes but is not limited to an agentId 721, a local pathId, the current call depth 723 and the current forkId 724. The agentId 721 is set to the agentId 104 of the agent 103 deployed to the local application. The local pathId 722 may uniquely identify an execution path of the current thread, the call depth 723 indicates the current depth of nested calls of instrumented methods and the forkId 724 indicates the current number of activations of other threads performed by the current thread.

The parent data section 710 identifies the execution path of the thread that invoked the current thread. It includes but is not limited to a parent agentId 711, a parent local pathId 712 and a forkId 713. The parent agentId 711 identifies the agent deployed to the application that activated the current thread; the parent local pathId 712 identifies the execution of the thread that activated the current thread and the parent forkId 713 identifies the activation of the current thread within all thread activations performed by the parent thread of the current thread.

The different types of event nodes are depicted in FIG. 8. Event nodes are sent from deployed entry sensors 111, exit sensors 112, tagging sensors 114, allocation entry sensors 120, allocation exit sensors 121, synchronization entry sensors 123, and synchronization exit sensors 124 to the agent 103 of the local application, which in turn forwards the event nodes to the correlation engine 307. Additionally, the VM Suspension Handler 1905 sends event nodes directly to the correlation engine in case of a received VM suspension notification. Sending event nodes may be performed using a computer network 118.

FIG. 8 a shows a start path event 801, which is sent to indicate the start of a new transaction or the start of the execution of a part of a transaction in a new thread. The parent data section 810 includes data that identifies the thread that started the current thread, whereas the data of the local data section 820 identifies the current thread. The parent data 810 includes but is not limited to a parent agentId 811, a parent local pathId 812 and a forkId 813. The parent agentId 811, parent local pathId 812 and forkId 813 identify application, thread execution and the activation of the current thread within all thread activations performed by the parent thread of the current thread. The local data 820 includes but is not limited to an agentId 821, a local pathId 822 and payload data 823. AgentId 821 and local pathId 822 identify the local application and the execution of the current thread. The payload data 823 includes but is not limited to data describing the current thread, like its name or id.

Path event nodes, as depicted in FIG. 8 b are used to indicate entry or exit of instrumented methods 110. A path event node contains an agentId 832 and a local pathId 833 which identify the application and the thread execution that originated the path event node. The entry/exit indicator 834 allows distinguishing between event nodes created by entry sensors 111 and exit sensors 112. The sensorId 835 is a key to the sensor context repository 109, and allows the reconstruction of the context of the sensor that created the path event node 831. The call depth 836 indicates the nesting depth of the instrumented method that created the path event node. The payload data 837 includes information about the current execution of an instrumented method 110. Payload data 837 may include but is not limited to method execution time, synchronization time or wait time of the instrumented method.

Path correlation event nodes 841, which are shown in FIG. 8 c, are used to indicate that a thread activated another thread, either explicitly, by calling a remote method or by sending a message. Path correlation event nodes allow reconstructing the sequence of thread activations performed by a thread. A path correlation node contains an agentId 842 and a local pathId 843, which identify the application and the thread execution that originated the path correlation event node. The sensorId 844 allows the reconstruction of the context of the sensor that created the path correlation event node 841 and the call depth 845 indicates the nesting depth. The forkId 846 indicates the sequence number of the thread activation described by the path correlation event.

FIG. 8 d describes allocation event nodes 851, which model heap memory allocations for creation of new objects. Such an event node contains an agentId 852, a local pathId 853, an entry/exit indicator 854 to indicate if an event was sent on entry or exit of an allocating method, a sensorId 855, the call depth 856, which indicates the nesting depth of the allocating method, and a payload data section 857 which may contain additional information about the allocated object, like its type.

FIG. 8 e describes synchronization event nodes 861, which indicates time spent for synchronization during execution of the transaction. Such an event node contains an agentId 862, a local pathId 863, an entry/exit indicator 864 to indicate if an event was sent on entry or exit of an allocating method, a sensorId 865, the call depth 866, which indicates the nesting depth of the synchronization method, and a payload data section 867 which may contain additional information about the performed synchronization, like the type of the used synchronization method.

FIG. 8 f describes runtime suspension event nodes 871, which indicates time elapsed during full or partial suspensions of the underlying virtual machine, which occurred during execution of the transaction. Such an event node contains an agentId 872, a local pathId 873, an entry/exit indicator 874 to indicate if the event was sent start or stop of the runtime suspension, a sensorId 875, the call depth 876, which indicates the nesting depth of the synchronization method, a full suspension indicator 877, which indicates if the entire virtual machine was suspended, or only a partial suspension, which may have only affected a single thread, occurred, and a payload data section 878 which may contain additional information about the performed runtime suspension.

FIG. 9 shows the process of transferring correlation information between to threads in case of explicit thread activation.

FIG. 9 a displays the execution of a tagging sensor 114, which is invoked in turn of the initialization of a thread switch. First, the tagging sensor 114 fetches the tag info node 701 from the thread local storage in step 901. Then, it queries if the local data 720 of the tag info node 701 is set in step 902. If the local data is not set, execution of the tagging sensor is terminated 906, because not existing data indicates that this thread switch is not performed by a traced transaction. Otherwise, the tagging sensor 114 creates a parent info node 601 which is initialized with the local data 720 of the tag info node 701 in step 903. In step 904, the parent info node 601 is stored in the object representing the thread which will be activated. An additional field to store the parent info node 601 was added to this object by the instrumentation engine via bytecode manipulation. In a final step 905, a path correlation event node 841 is initialized with the data from the tag info node 701 and afterwards sent to the correlation engine 307. Additionally, the forkId 724 of the tag info node 701 is incremented.

FIG. 9 b shows the execution of a tag extraction sensor 116 which is executed on the start of a thread. In an initial step 910, it is checked if the object representing the current thread contains a valid parent info node 701. In case of no existing parent info node, the execution of the tag extraction sensor 116 is terminated in step 914. Otherwise execution continues with step 911 which creates a new tag info node 701 and resets its local data section 720. In the subsequent step 912, the information extracted from the parent info node 601 is stored in the parent data section 710 of the tag info node 701, and in a final step 913 the tag info node is stored in the local storage of the current thread.

FIG. 10 shows the transfer of correlation information within a remote method call, whereas FIG. 10 a describes how a tagging sensor is attaching correlation information in form of a parent info node 601 to a message representing a remote method invocation 404 at the caller side of the remote method. In step 1001, the tag info node 701 is retrieved from the thread local storage and step 1002 checks if the local data 720 is initialized. If the local data is initialized, execution continues with step 1003 by creating and initializing a parent info node 601 with data from the tag info node 701 retrieved in step 1001. In step 1004, the parent info node 601 is attached to the message representing the remote method call 404. In a final step 1005, a path correlation event 841 is initialized and sent to the correlation engine 307 and the forkId 724 of the tag info node 701 is incremented.

FIG. 10 b displays how a tag extraction sensor 116 extracts the parent info received with a remote method message 404 on execution of the remote method service routine 407. In a first step 1010 the sensor checks if the remote method message 404 contains a parent info node 601. If a parent info node is found, it creates a tag info node 701 and resets its local data section 720 in step 1011, initializes the parent data section 710 with data from the received parent info node 601 in step 1012 and stores the tag info node in the thread local storage in step 1013.

The transfer of correlation information within messages is depicted in FIG. 11. FIG. 11 a shows how a tagging sensor stores correlation information in a message parameter. In an initial step 1101, the tag info node 701 is retrieved from the thread local storage, and in a subsequent step 1102 the tagging sensor 114 checks if the local data 720 of the tag info node 701 is set. If the local data is set, a parent info node 601 is created and initialized in step 1103, and in step 1104 the parent info node is stored in the message which is going to be sent 504 as an additional message parameter. Finally, in step 1105, the tagging sensor 114 initializes and sends a path correlation event node 841 and increments the forkId 724 of the tag info node 701.

FIG. 11 b shows how a tag extraction sensor 116, which is invoked in course of receiving a message, extracts correlation information from the received message 507 and stores it in the thread local storage. In a first step 1110, the sensor checks if the received message contains a parameter with a parent info node 601. If a parent info node is available, a tag info node 701 is created, its local data is reset in step 1111, and parent data of the tag info node 701 is initialized with data from the received parent info node in step 1112. Finally, the tag info node 701 is stored in the thread local storage in step 1113.

Transfer of correlation information between communicating threads as described in present invention is not restricted to explicit thread switch, remote method invocation and messaging. Any communication channel between threads that allows adding user defined data can be used to transfer correlation information. As an example, correlation information could be transferred between the client and the server of a web service request by adding an additional header field to the request representing the web service call. The additional header field may be used to transfer correlation information.

The execution of an entry sensor 111 is depicted in FIG. 12. Calls to entry sensors are inserted at the start of each instrumented method 110 by the instrumentation engine 108. In an initial step 1201, the entry sensor checks if the local data 720 of the tag info node 701 in the thread local storage is initialized. If no tag info node is found in the thread local storage, a new tag info node is created, local and parent data are reset and the new tag info node is added to the thread local storage. If the local data of the tag info node is set, payload data is acquired in step 1202. Payload data may contain, but is not restricted to execution time, synchronization time or argument values of the current method. In step 1203, the call depth 723 of the tag info node 701 is incremented and in a subsequent step 1204, a path event node 831 is created and initialized with a agentId 721, local pathId 722 and call depth 723 from the tag info node 701. Additionally the sensorId 835, which identifies the context of the entry sensor 111, is set. The entry/exit indicator 834 is set to “entry” and the acquired payload data is stored in the path event node. In step 1205 the path event node is sent to the correlation engine 307.

In case of not set local data 720, the entry sensor 111 executes step 1206 and generates a new local pathId 722, which uniquely identifies a thread execution within the scope of a virtual machine. Additionally, it retrieves the agentId 104 from the agent 103 deployed to the application. Both local pathId 722 and agentId 104 are stored in the tag info node 701 of the local thread storage, and call depth 723 and forkId 724 of the tag info node 701 are reset.

In a subsequent step 1207, payload data specific for a started local execution path is acquired, which may contain the start time of the path, or an indicator about the event causing the start of the execution, like handling a message or executing a remote method.

In step 1208 the entry sensor creates a start path event 801, sets local pathId 821, agentId 822 with data from the tag info node 701, stores the acquired payload data to the payload data 823. Afterwards the entry sensor 111 checks in step 1209 if the parent data 710 of the tag info node 701 is set. If the parent data 710 is set, the entry sensor initializes the parent data 810 of the start path event node 801 with the parent data 710 of the tag info node 701 in step 1210. Otherwise, parent data 810 of the start path event node 801 is reset in step 1211. Afterwards, the start path event 801 is sent in step 1212 and execution of the entry sensor continues with step 1202 and subsequent steps.

The execution of an exit sensor 112 is depicted in FIG. 13. Each time an instrumented method 110 is exited, an exit sensor 112 may be invoked. The exit sensor checks in an initial step 1301 if the local data 720 of the tag info node 701 in the local thread storage is set. If no local data is set, the current execution of the method belongs to no monitored execution path. In this case, the execution of the exit sensor 112 is terminated in step 1308. Otherwise, execution continues with step 1302 which acquires pay load data of the exit sensor 112. The payload data may contain, but is not restricted to execution time, synchronization time or CPU time of the current method. Afterwards, a path event node 831 is created in step 1303 and its agentId 832, local pathId 833 and call depth 836 are initialized with the corresponding values from the tag info node 701 of the thread local storage. The sensorId 835 is initialized with a value identifying the current method, the entry/exit indicator 834 is set to “exit” and the payload data 837 is initialized with the previously acquired values. In step 1304 the initialized path event node is sent to the correlation engine 307 and the call depth 723 of the tag info node in the thread local storage is decremented in step 1305. If it is detected in step 1306 that the call depth has now a value of 0, then the tag info node 701 in the local thread storage is reset in step 1307. A call depth of 0 indicates that execution of the outermost instrumented method within the current execution of the current thread is finished and thus the values of the tag info node 701 are no longer valid.

FIG. 14 depicts different types of path nodes, which are used by the correlation engine to represent monitored execution paths. A start path node 1401 which is shown in FIG. 14 a contains a parent path section 1410, which is used to store information to correlate the current execution path with a potential parent execution path which triggered the current execution path. The parent path info section 1410 contains a parent pathId 1411, a parent agentId 1412, which are used to identify the parent execution path, and a forkId 1413 which is used to identify the position within the parent execution path where the current execution path was activated. The path info section 1420 includes a pathId 1421 to identify the execution path within the virtual machine, an agentId 1422 to identify the virtual machine that executed the path, payload data 1423 which may contain information about the execution path, like name or id of the thread that performed the execution, a field path nodes 1424, which includes a list of path nodes 1431 and path correlation nodes 1441 belonging to the path. The entries of the path nodes list 1424 of a start path node 1401 are sorted according to the arrival time of the corresponding method entry path event nodes 831 and path correlation event nodes 841 at the correlation engine 307. Path event nodes 831 and path correlation nodes 841 are sent to the correlation engine 108 via one network communication channel and arrive at the correlation engine in the same sequence as they were sent by the agent 103. Thus, the sequence of the path nodes in a path node list 1424 is equivalent to the execution order of the methods represented by the path nodes.

The field temporary correlation nodes 1425 contains path correlation nodes 1441 which link the current execution path with associated child execution paths, where data describing the child paths arrived at the correlation engine 307 before the corresponding path correlation event node arrived. This situation may occur e.g. if in case of a remote method invocation, the network latency between the calling application and the correlation engine is higher than the network latency between the callee application and the correlation engine.

FIG. 14 b describes a path node 1431 which represents one execution of an instrumented 110 method within an execution path. A path node contains payload data 1432, sensorId 1433 and call depth 1434. Payload data contains data describing one execution of an instrumented method, which may contain but is not limited to execution time, synchronization time, CPU time or argument values. The sensorId 1433 allows the reconstructing of the context of the sensor that caused the created of the path node 1431. The field call depth 1434 stores the nesting level of the current instrumented method.

FIG. 14 c shows a path correlation node 1441 which is used to map interdependencies between different parts of distributed execution paths. A path correlation node contains the fields, forkId 1442, sensorId 1443, call depth 1444 and child path references 1445. The forkId 1442 identifies activations of other threads, performed by the current thread, within the scope of the current thread. Activations of other threads may be performed by explicit thread activation, remote method invocation or sending of messages. The list child path references 1445 may include references to paths triggered by the thread activation described by the current path correlation node 1441. The functionality of sensorId 1443 and call depth 1444 is as specified in the description of FIG. 14 b.

FIG. 14 d, FIG. 14 e and FIG. 14 f describe allocation path nodes 1451, synchronization path nodes 1461 and runtime suspension nodes 1471. Functionality of sensorId (1453, 1463 and 1473) and call depth (1454, 1464 and 1474) is as explained in description of FIG. 14 b.

The allocation payload data 1452 of an allocation path node 1451 may contain but is not limited to information about the new allocated object, like the type of the allocated object, the used allocation method or an indicator indicating whether a plain new object was created, or a serialized object was deserialized.

The synchronization payload data 1462 of a synchronization path node 1461 may contain but is not limited to information about the type of the used synchronization method, and the runtime suspension payload data 1472 of a runtime suspension path node 1471 may contain additional information about the occurred runtime suspension.

The process depicted in FIG. 15 shows the processing of an incoming start path event node 801 by the correlation engine 307. A start path event node 801 is transformed into a start path node 1401, which is inserted into the path repository 308. Each start path node 801 represents one execution path of a thread.

After receiving a start path event node 801, the correlation engine first queries the path repository 308 for an existing start path node 1401 with the same pathId and agentId as the received start path event in step 1501. If such a start path node is found, the payload data of the start path node is updated with the payload data of the received start path event node 801 in step 1504. Otherwise, a new start path node 1401 is created and inserted into the path repository 308 and its path info section 1420 is initialized with data from the local data section 820 of the incoming start path event node 801 in step 1503. The correlation engine checks in step 1505, if the parent data section 810 of the received start path event node 801 is initialized, and resets the parent path info section 1410 of the created or updated start path node 1401 in step 1506, if the parent data 810 of the received start path event node is not initialized, and terminates the processing of the received start path event in step 1517. Otherwise, the correlation engine 307 initializes the parent path info section 1410 of the start path node 1401 with the data from the received start path event node 801 in step 1507. Afterwards, it queries the path repository 308 for a start path node 1401 representing the parent path addressed by the received start path event node 801 in step 1508. If no matching start path node 1401 is found, the correlation engine creates a new start path node 1401 and initializes its pathId 1421 and agentId 1422 with parent local pathId 812 and parent agentId 811 from the received start path event node 801 in step 1510. Additionally, a path correlation node 1441 is created, and added to the temporary correlation nodes 1425 of the start path node 1401 created in step 1510. The forkId 1442 of the created path correlation node 1441 is initialized with the forkId 813 of the received start path event node 801, and a reference to the start path node 1401, created or updated in step 1503 or 1504, which represents the path described by the received start path event node 801, is added to the child path references 1445 of the created path correlation node 1441. SensorId 1443 and call depth 1444 of the path correlation node are reset. After execution of step 1510, processing of the received start path event is terminated in step 1517.

If a start path node 1401 representing the parent execution path was found in step 1508, execution continues with step 1511, where the correlation engine queries the path nodes 1424 of the found parent path for a path correlation node with a forkId 1442 as the forkId 813 of the received start path event node 801. If such a path correlation node 1441 is found, a reference to the start path node 1401 which was created or updated in step 1503 or 1504 is added to the child path references of the path correlation node in step 1516, and the processing of the received start path event node 801 is terminated in step 1517.

If no path correlation node 1441 is found in step 1511, execution continues in step 1513, and the temporary correlation nodes of the start path node 1401 are queried for a path correlation node with a forkId 1442 as the received forkId 813. If a corresponding path correlation node is found, execution continues with step 1516, which adds a reference to the created or updated start path node 1401 to the child path referenced 1445 of the found path correlation node 1441. Otherwise, a new path correlation node 1441 is created and added to the temporary correlation nodes 1425 of the start path node 1401 in step 1515. The forkId 1442 of the created path correlation node 1441 is set to the forkId of the received start path event 801 and sensorId 1443 and call depth 1444 are reset. After step 1515, execution continues with step 1516.

The processing of an incoming path correlation event 841 by the correlation engine 307 is shown in FIG. 16. On receiving a path correlation event 841, the correlation engine first checks if a start path node 1401 with pathId 1421 and agentId 1422 equal to local pathId 843 and agentId 842 of the received path correlation event node 841 exists in the path repository 308. If no corresponding start path node 1401 is found, the path correlation event 1441 is ignored (step 1605) and processing of the event is finished.

Otherwise, the temporary correlation nodes 1425 of the start path node 1401 found in step 1601 are queried for a path correlation node 1441 with forkId 1442 matching the forkId 846 of the received path correlation event node 841. If the temporary correlation nodes 1425 do not contain a matching path correlation node 1441, a new path correlation node is created, initialized with the data of the received path correlation event node 841 and appended to the path nodes 1424 of the start path node 1401 found in step 1601. Otherwise, the path correlation node 1441 found in step 1603 is removed from the temporary correlation nodes 1425, call depth 1444 and sensorId 1443 are initialized with the corresponding values of the received path correlation event node 841, and the path correlation node 1441 is appended to the path nodes 1424 in step 1607.

FIG. 17 describes the processing of an incoming path event node 831 by the correlation engine 307. In step 1701 the correlation engine 307 checks if a start path node 1401 with agentId 1422 and pathId 1421 equal to the local agentId 832 and local pathId 833 of the received path event node exists in the path repository 308. If no matching start path node 1401 is found, the incoming path event node 801 is ignored (step 1703) and processing of the event is finished.

Otherwise, the correlation engine evaluates the entry/exit indicator 834 of the path event node 831 to determine if the received path event node described entry or exit of an instrumented method 110 in step 1705. If the received path event node 831 describes a method entry, a new path node 1431 is created, payload data 1432, sensorId 1433 and call depth 1434 are initialized with the corresponding values of the received path event node 831 and the path node 1431 is appended to the path nodes 1424 of the start path node 1401 found in step 1701. If the correlation engine 307 detects in step 1705 that the received path event node 831 describes a method exit, the correlation engine 307 queries the path nodes 1424 of the start path node 1401 found in step 1701 for a path node 1431 representing the corresponding method entry event in step 1706. The corresponding path node 1431 representing the corresponding method entry is detected by scanning the path nodes 1424 of the start path node 1401 found in step 1701 backwards, beginning with the last added path node 1431 until a path node 1431 describing a method entry with the same call depth 1434 as the received path event node 831, which describes a method entry is found, and which has the same sensorId 1433 as the received path event node 831. The first detected path node matching these criteria is the path node 1431 that describes the corresponding method entry.

In a final step 1707, the payload data 1432 of the path node 1431 found in step 1706 is merged with the payload 837 of the received path event node 831. Merging of payload may contain but is not limited to calculating the execution duration of the method call described by the path node 1431, adding captured method return values to the payload 1432 of the path node 1431, or setting a flag in the path node 1431 indicating that execution of the described method is terminated.

The separate signalization of method entries and method exits by the agent 103 allows the correlation engine 307 to provide valid descriptions of execution paths while execution of the paths is still ongoing. Together with a concurrent access of correlation engine 307 and analysis module 309 to the path repository 308, this provides real-time visualization of execution paths, while execution is still ongoing. This mechanism is especially useful in visualizing the execution of paths which are blocked, because it allows the visualization of all method entries, up to the method that caused the block.

FIG. 18 describes the execution of an allocation sensor. A parent thread 301 executes an instrumented method, which in turn executes an instrumented allocation method 119. On entry of the allocation method, the allocation entry sensor 120 is executed and on exit of the allocation method, the allocation exit sensor 121 is executed. Both sensors send event nodes to the agent 103, which in turn forwards these event nodes to the correlation engine 307. For a detailed description of the processes performed by the allocation entry and exit sensors please refer to descriptions of FIG. 21 a and FIG. 21 b.

FIG. 19 describes the execution of an allocation sensor. A parent thread 301 executes an instrumented method, which in turn executes an instrumented synchronization method 122. On entry of the synchronization method, the synchronization entry sensor 123 is executed and on exit of the synchronization method, the synchronization exit sensor 124 is executed. Both sensors send event nodes to the agent 103, which in turn forwards these event nodes to the correlation engine 307. For a detailed description of the processes performed by the allocation entry and exit sensors please refer to descriptions of FIG. 22 a and FIG. 22 b.

FIG. 20 describes the architecture used to monitor runtime suspension of the virtual machine 102. To run maintenance tasks, like running a major garbage collection, or performing a recompilation of bytecode to increase performance, full or partial suspension of execution of the application 101 is required. Monitoring and debugging interfaces, like the JVMPI interface provided by Suns Java VM provide notifications on such suspensions, which may be used to detect runtime suspensions which occurred during execution of a transaction.

A VM Suspension Notification Handler 2005 is deployed to the virtual machine runtime 2001 and is registered get notified on relevant events indicating full or partial runtime suspensions. Those runtime suspension notifications are modeled here by VM suspension notifications 2002, which may map to garbage collection start/stop notifications etc. Such a VM suspension notification may contain an entry/exit indicator 2003, indicating if the VM enters or exits the suspension state. Additionally, it may contain a threadId 2004, which identifies a suspended thread in case of a partial suspension, affecting only one thread. The threadId 2004 may be set to a special value, indicating a full suspension, affecting all threads.

The VM Suspension Notification Handler 2005 receives VM suspension notifications 2002, transforms them into appropriate event nodes and sends them to the correlation engine 307. For a detailed description of this process, please refer to description of FIG. 23.

FIG. 21 describes the process performed during executing allocation entry and exit sensors. FIG. 21 a shows the process performed on entry of an allocation method. In a first step 2101, it is checked if the thread local storage contains a valid tag info node 701, with set local tag info 720. If no local tag info 720 is available, the process is exited in step 2108. Otherwise, the local tag info 720 is received from the thread local storage in step 2102, and a local boolean variable “trace” is declared and initialized with false at step 2103. In step 2104 an allocation stack is fetched from the thread local storage. If no allocation stack is available, a new, empty one is created and stored in the thread local storage.

The allocation stack contains references to objects created by the allocation method. If the allocation method in turn calls other instrumented allocation methods which create other instances, references to those instances will be pushed on top of the stack. The local “trace” variable and the allocation stack are used to avoid sending allocation entry/exit events in case of delegating constructors. A delegating constructor is an allocating method, which in turn calls other allocating methods on the same object instance to allow code reuse.

Step 2105 fetches the top level element from the allocation stack and compares it with the currently allocated object. If step 2106 detects that the top level element equals the currently allocated object, the process is exited in step 2110. Otherwise, step 2107 increments the call depth, 2108 creates, initializes and sends an allocation event 851 indicating the entry of an allocation method 119 and step 2109 pushes a reference to the currently allocated object to the allocation stack.

FIG. 21 b shows the process performed on exiting an allocation method 119. In a first step 2120, it is checked if the local variable “trace” is available and set to “true”. If no local variable “trace” is available, or it is set to “false”, the process is terminated in step 2126. Otherwise, a new allocation even node 851 indicating an exited allocation method 119 is created, initialized and sent to the correlation engine 307. Step 2122 decrements the call depth and step 2123 removes the reference to the currently allocated object from the allocation stack. If it is detected that the allocation stack is now empty in step 2124, it is removed from the thread local storage in step 2125.

FIG. 22 depicts the process of entering and exiting a synchronization method 122, whereas FIG. 22 a shows the process of executing a synchronization entry sensor 123 and FIG. 22 b shows the process of executing a synchronization exit sensor 124.

On executing a synchronization entry sensor 123, it is first checked in step 2201 if a tag info node 701 with initialized local data 720 is available in the thread local storage. If no initialized local data is available, the process is exited in step 2205. Otherwise, the tag info node is fetched from thread local storage in step 2202, call depth is increased in step 2203 a synchronization event 861, indicating entry of a synchronization method 122 is created, initialized and sent to the correlation engine in step 2205.

On executing a synchronization exit sensor 124, it is first checked in step 2210 if a tag info node 701 with initialized local data 720 is available in the thread local storage. If no initialized local data is available, the process is exited in step 2214. Otherwise, the tag info node is fetched from thread local storage and a synchronization event 861, indicating exiting a synchronization method 122 is created in step 2211, and call depth is increased in step 2212.

The process of transforming incoming VM suspension notifications 2002 into runtime suspension event nodes 871 is shown in FIG. 23. In an initial step 2301 it is checked, if an agent 103 is deployed to the virtual machine 102. If no agent is available, the process is exited in step 2309. Otherwise a new runtime suspension event node 871 is created and initialized with the agentId 104 of the agent 103 and the entry/exit indicator of the received VM suspension notification 2002 in step 2302. In step 2303, the threadId 2004 is fetched from the received VM suspension notification 2002 and checked if it indicates a thread suspension or a full suspension. If the threadId 2004 indicates a full suspension, the full suspension indicator of the runtime suspension event node 871 is set in step 2304 and the event node 872 is sent in step 2308.

If the threadId 2004 indicates a thread specific suspension, the tag info node 701 is fetched from the thread referred by the received threadId 2004 in step 2305. Step 2306 checks if a tag info node is available and contains valid local data 720. If no valid local data is available, the process is exited in step 2309. Otherwise, the local pathId 722 is fetched from the local data 720 and stored in the created runtime suspension event node 871. Afterwards, the event node 872 is sent in step 2308.

FIG. 24 describes the processing of an incoming path event node 851 by the correlation engine 307. In step 2401 the correlation engine 307 checks if a start path node 1401 with agentId 1422 and pathId 1421 equal to the local agentId 832 and local pathId 833 of the received allocation event node 851 exists in the path repository 308. If no matching start path node 1401 is found, the incoming path event node 801 is ignored (step 2403) and processing of the event is finished.

Otherwise, the correlation engine evaluates the entry/exit indicator 854 of the path event node 851 to determine if the received path event node described entry or exit of an instrumented method 119 in step 2405. If the received path event node 851 describes an allocation method entry, a new path node 1451 is created, allocation payload data 1452, sensorId 1453 and call depth 1454 are initialized with the corresponding values of the received path event node 851 and the path node 1451 is appended to the path nodes 1424 of the start path node 1401 found in step 2401. If the correlation engine 307 detects in step 2405 that the received allocation path event node 851 describes an allocation method exit, the correlation engine 307 queries the path nodes 1424 of the start path node 1401 found in step 1701 for a allocation path node 1451 representing the corresponding method entry event in step 2406. The corresponding path node 1451 representing the corresponding method entry is detected by scanning the path nodes 1424 of the start path node 1401 found in step 1701 backwards, beginning with the last added allocation path node 1451 until an allocation path node 1451 describing an allocation method entry with the same call depth 1454 as the received path event node 851, which describes an allocation method entry is found, and which has the same sensorId 1453 as the received allocation path event node 851. The first detected path node matching these criteria is the allocation path node 1451 that describes the corresponding method entry.

In a final step 2407, the allocation payload data 1452 of the path node 1451 found in step 2406 is merged with the allocation payload 857 of the received allocation path event node 851. Merging of payload may contain but is not limited to calculating the execution duration of the allocation method call described by the path node 1451.

FIG. 25 describes the process of correlating synchronization event nodes 861 to a transaction path. The same process is performed as for received allocation path events 851, with the exception that synchronization event nodes 861 are correlated instead of allocation path events 851. For details please see description of FIG. 24.

FIG. 25 describes the process of correlating runtime suspension event nodes 871 to a transaction path. In a first step 2601 it is checked if the received event node 871 describes a suspension of a specific thread. In case of a suspension of a specific thread, the same process which is performed for received allocation path events 851, with the exception that runtime suspension event nodes 871 indicating the suspension of a specific thread are correlated instead of allocation path events 851. For detailed information please see description of FIG. 24.

If the received runtime suspension event 871 indicates that a full suspension occurred, step 2609 is performed which queries the correlation engine 307 for all start path nodes 1401 where the agentId 1422 matches the agentId 872 of the received runtime suspension event 871 and where not all expected event nodes indicating method exits were received. The received set of start path nodes describes all paths of the currently suspended virtual machine which are not finished. The received runtime suspension event 871 is correlated to the transaction path represented by each of those start path events 1401. Correlation is performed in the same way as described for thread specific suspension, except that querying an associated path is not required, because the affected paths were already determined in step 2609.

An overview of a monitored system which is currently executing a monitored transaction that performs an internal thread communication is shown in FIG. 27. The monitored transaction is started on the client application 2701, where an instrumented method 110 is executed by a thread 2702 running on the client application 2701. On entering the instrumented method, an entry sensor 111 is executed, which sends path events indicating a new monitored thread execution, and indicating the execution of a specific instrumented method 110 to the agent 103. The agent forwards the path events to a connected correlation engine 307 for correlation.

Afterwards, the instrumented method 110 invokes a thread communication method 2703 which sends a thread communication message 2704 to a monitored server application 2706 and which causes the execution of a tagging sensor 114. The tagging sensor creates a path event which describes the performed initialization of a thread communication and sends it to the agent 103 deployed to the client application 2701, which forwards it to the correlation engine 307. Either the tagging sensor or the nearest enclosing entry sensor may additionally capture data describing the started thread communication. This data may contain but is not limited to a request URL in case of a thread communication in form of a HTTP request or a web service request, or a remote method server name and a remote method name in case of a remote method call. Additionally, data describing state information of the executed thread communication may be captured by the tagging sensor or the nearest enclosing exit sensor. The state information may, e.g., indicate whether or not the thread communication was successful. For example, in the case of HTTP requests or web service requests, the state information may be contained within an HTTP status code that indicates whether the corresponding HTTP request or web service request was processed successfully (e.g., whether the resource requested by the HTTP request was provided successfully in response to the HTTP request). The captured data may either be stored in the payload data 837 of path event nodes 831 created by the entry and exit sensors, or in a new introduced payload data field of the path correlation node 841 created by the tagging sensor.

Additionally, the tagging sensor creates a parent info node 601 and attaches it to the thread communication message 2704 before it is sent to the server application 2705. The path info node 601 contains correlation data to identify the client application 2701 and the thread 2702 that sent the thread communication message 2704. The tag info node 701 of the sending thread 2702 may be used to initialize the parent info node. After the thread communication 2703 is finished, and the instrumented method 110 terminates, an exit sensor 112 is executed which reports the exit of the instrumented method 110 in form of a path event.

The agentId 821, 832 and 842 of the path events sent by the client application are set to the agentId 104 of the client application 2701, which may be used to identify the client application 2701 as the origin of those path events, and their local pathId 822, 833 and 843 are set to a value identifying the corresponding thread execution 2702 which executed the methods (including the thread communication method) described by those path events. The receiving correlation engine 307 processes the received path events as described in FIGS. 15 to 17 and creates path nodes describing the monitored client side transaction execution.

The server application 2705 receives the thread communication message 2704 and creates a thread 2706 to handle the incoming thread communication message 2704 in a communication service method 2707. Executing the communication service method 2707 causes the execution of a tag extraction sensor 116 which is instrumented at the start of the communication service method. The tag extraction sensor 116 extracts the agentId 602 and local pathId 603 from the received path info node, and stores it as parent agentId 711 and parent local pathId 712 of the tag info node 701 of the thread 2706 executing the communication service method 2707. Afterwards, an instrumented method 110 is executed which causes the execution of an entry sensor 111 and an exit sensor 112, which create a start path event 801 indicating a new monitored thread execution, and path events 831 indicating entry and exit of an instrumented method 110. Parent agentId 811 and parent local pathId 812 are set to the values extracted from the received parent info node. The agentIds 821, 832 and 842 are set to the agentId 104 of the server application 2705, and the local pathId 822, 833 and 843 are set to a value identifying the server side thread 2706 that handles the incoming thread communication message 2704.

For a detailed description of the execution of tagging sensors, tag extraction sensors, entry sensors and exit sensors, please see FIGS. 9 to 13 and corresponding descriptions.

The created path events are sent to a connected correlation engine 307. The correlation engine processes the received path events as described in FIGS. 15 to 17 and creates path nodes describing the server side transaction and connects the tracing data describing server side transaction execution with the tracing data describing the client side execution.

The network of path nodes as described in FIG. 28 shows the resulting tracing data of the monitored transaction execution described in FIG. 27. In FIG. 28, and elsewhere in this patent application, reference numbers of the form 14XXn (such as 1401 a and 1401 b) are instances of the corresponding element having reference number 14XX (e.g., 1401) in U.S. patent application Ser. No. 12/191,409, filed on Aug. 14, 2008, Attorney Docket Number D0004-1004. The start path node 1401 a represents the execution of the client thread which performed the client part of the monitored transaction. Its parent path info section 1410 a is not set, which indicates that the described thread execution was triggered either by a user interaction or by an incoming request. The path info section 1420 a identifies the thread execution by the client application that performed the client part of the monitored transaction. The pathId 1421 a may e.g. be set to “1” to identify the thread execution 2702 within the client application, and its agentId 1422 a may be set to “client” to identify the client application. The path nodes 1424 a may contain a list of path nodes 1431 and path correlation nodes 1441 which represent the sequence and nesting level of monitored method invocations and thread communications for this thread execution. The reference to the first path nodes entry 2801 may point to the path node 1431 a describing the first monitored method execution (see, e.g., element 110 in FIG. 27). The payload data 1432 a may contain performance data of the described method execution and additionally data describing the enclosed thread communication, e.g., in the form of an URL if the thread communication is performed via a HTTP or web service request. The sensorId 1433 a may be set to a value to identify a corresponding sensor context node 201, and the call depth 1434 a is set to “1” which indicates the nesting level of the monitored method execution. The reference to the next path nodes entry 2802 refers a path correlation node 1441 a, which describes the client side part of the thread communication performed by the monitored transaction in the form of the execution of a thread communication method 2703. Its forkId 1442 a is set to “1” to indicate that this is the first monitored thread communication of the thread execution described by the start path node 1401 a. The sensorId 1443 a points to a sensor context node 201 describing the sensor that was executed during the execution of the thread communication method 2703. This sensor context node may be used to identify the type of the thread communication used by the thread communication method 2703, which may, e.g., be a HTTP or web service request, a remote method call or posting of a message. The call depth 1444 a is set to “1” because the monitored thread execution was performed by a method with call depth “1” (described by the previous path node 1431 a). The child path references list 1445 a contains a list of start path nodes 1401 which match the path correlation node. Those matching start path nodes describe the server side handling of the thread communication caused by the thread communication described by the path correlation nodes 1441. Matching start path nodes have a parent pathId 1411 and a parent agentId 1412 as the start path node 1401 which contains the path correlation node, and which has the same forkId 1413 as the path correlation node 1442.

In the described example, the start path node 1401 b which describes the part of the monitored transaction which was executed by a thread on the server application, matches the path correlation node 1441 a because its patent pahtId 1411 b and parent agentId 1412 b match the pathId 1421 a and agentId 1422 a of the start path node 1401 a, and because the forkIds of start path node 1401 b and path correlation node 1441 a match.

The pathId 1420 b and agentId 1421 b of the start path node 1401 b identify the thread execution 2906 on the server application 2905. The path nodes list 1424 b contains a path node 1431 b which describes the monitored server side execution of an instrumented method.

It is noteworthy that the availability of a reference to a start path node 1401 in the child path references list 1445 a of path correlation node 1441 a is an indicator that the thread communication described by the path correlation node 1441 a was directed to an application which is monitored by the same monitoring system as the application that sent the thread communication. This information may be used to tag the recorded thread communication as internal.

FIG. 29 shows a monitored system which currently executes a monitored transaction which performs a thread communication which is directed to a server application which is not instrumented. The client side transaction execution and monitoring is the same as described in FIG. 27. However, the thread communication message 2704, which is tagged with a parent info node 601 containing correlation information to identify the sender application 2701 and thread 2702, is received by a server application 2905 which is not instrumented. The server application spawns a thread 2906 to handle the incoming thread communication message 2704 by a communication service method 2907, which in turn calls another method 2908. Since, however, the server application is not instrumented, no sensors are executed and no path events are sent that describe the server side part of the transaction execution.

One reason for a server not to be instrumented is that the server application is hosted by a different organization than the one hosting the monitored client application. An example for such a situation would, e.g., be an e-commerce application which receives a purchase request, containing article data and credit card transaction data via an incoming request. The e-commerce application may perform internal operations, like checking the availability of the requested article, and it may forward credit card transaction data to an external credit card transaction server for verification and authorization.

FIG. 33 of U.S. patent application Ser. No. 12/971,408 illustrates another situation where a monitored transaction initializes a thread communication which is directed to a not instrumented application. FIG. 30 shows the tracing data created by the execution of the transaction as described in FIG. 29. A start path node 1401 c identifies the client side transaction execution performing the monitored transaction. Its parent path info 1410 c is not set, indicating that the transaction initialized by an incoming request or by a user interaction, its agentId 1422 c and pathId 1421 c identify the client application 2701 and the thread execution 2702 on the client application.

The path nodes list 1424 c of the start path node 1401 c contains path node 1431 c, which describes the execution of the instrumented method 110 on the client, followed by path correlation node 1441 c, which describes the thread communication method 2703 executed by the monitored transaction. The forkId 1442 c may be used to identify a specific execution of thread communication method out of the sequence of multiple monitored thread communications performed by the method execution described by the previous path node. The sensorId 1443 c may be used to identify the type of the performed thread communication method 2703. Call depth 1444 c is set to the same value as the call depth 1434 c of the previous path node 1431 c. The child path references list 1445 c contains references to monitored server side processing of the thread communication described by the path correlation node 1441 c. In this example, the child path references list 1445 c is empty, because the thread communication was directed to the not instrumented server application 2905, which did not create tracing data for the server side part of the monitored transaction. The fact that the child path references list 1445 c is empty may be used to mark the thread communication described by path correlation node 1441 c as outgoing.

FIG. 31 describes the process which determines if monitored thread communications performed by a thread execution described by a finished start path node 1401 are outgoing. A start path node 1401 is finished, when the execution of the monitored transaction within the thread is finished, i.e., when the top most instrumented method within the thread has exited, and no more path events describing thread executions triggered by thread communications performed by the thread execution described by the finished start path node can be expected. The determination whether a start path node 1401 is finished may, for example, be timeout based, or by using the methods and concepts described in U.S. patent application Ser. No. 12/971,408.

To implement a timeout based completion detection method, the point of time when the path event indicating the end of a monitored thread execution described by a first start path node 1401 needs to be recorded. This would be the event that indicates the exit of the top most instrumented method. This indicates that no path events describing the start path node 1401 can be expected. But it does not guarantee that all start path nodes describing thread executions triggered by thread communications described by the first start path node are already available. To guarantee that all start path nodes triggered by thread communications by the first start path node are available, further processing of the first start path node which relies on finished correlation of the start path nodes triggered by thread communications of the first start path node must be delayed until it can be guaranteed that all corresponding path events reached the correlation engine. The minimal delay period may be calculated as follows: max time a request travels from the client application to a server application+max server side request execution time+max time a path node travels from server application to correlation engine. Examples for such a delay period would e.g. be 30 seconds for locally distributed applications communicating via LAN, and 2-5 minutes for globally distributed applications communication via WAN.

A start path node 1401, for which the time when the path event indicating the end of the described thread execution was recorded, and for which this time is further in the past than the minimal delay period, is considered as finished.

After a finished start path node 1401 is selected in initial step 3101, the process searches the path nodes 1424 of the selected start path node for a path correlation node 1441 in step 3102. If no path correlation node is found, the process ends with step 3110. Otherwise, the process continues with step 3105 and fetches the sensor context node 201 matching the sensorId 1443 of the found path correlation node 1441 from the sensor context repository 109. The sensor context node may be used to determine the type of performed thread communication, which may, e.g., be a HTTP request, a web service request, or a remote method call. Subsequent step 3105 fetches the number of references to start path nodes 1401 stored in the child path references list 1445 of the path correlation node 1441. If step 3106 determines that child path references are available, the process continues with step 3109, which visualizes the described thread communication as internal and the process continues with step 3102 to find the next path correlation node. If otherwise step 3106 determines that no child path reference is available in the child path references list 1445 of the path correlation node 141, the process continues with step 3107 to retrieve meta-data about the described thread communication. The meta-data may contain data to identify the target of the thread communication, e.g., a request URL in the case of an HTTP request or web service request based communications. Additionally, the meta-data may contain data describing the status of the performed thread communication, like a HTTP status code for HTTP request or web service request based communications. The communication meta-data may either be captured by the corresponding tagging sensor and sent and stored as payload data of path correlation event nodes 841 and path correlation nodes 1441, or it may be captured by entry 111 and exit sensors 112 placed to the same method as the tagging sensor, and sent and stored as payload data of path event nodes 831 and path nodes 1431. Subsequent step 3108 visualizes the thread communication described by the path correlation node as outgoing and enriches the visualization with previously fetched communication target and status data. Afterwards, the process continues with step 3102 to fetch the next path correlation node.

As aforementioned, capturing of thread communication meta-data may be performed by instrumenting thread switching methods 113 not only with a tagging sensor 114, but also with an entry sensor 114 placed at the beginning of the thread switching method and an exit sensor at the end of the thread switching method. The entry sensor would be configured to capture communication target data using, e.g., argument value capturing, and the exit sensor would capture communication status information using, e.g., return value capturing. The captured thread communication meta-data would then, after finishing correlation, be available in the payload data 1432 of the path node 1431 in the path nodes list 1424 directly before a path correlation node.

The data capturing and correlation processes described earlier, require the execution of a tag extraction node 116, followed by execution of an entry sensor 111 and an exit sensor to detect a child thread execution. In some rare cases, the execution of a communication service method 2707 may never invoke an instrumented method, even if the executing application is instrumented, because the execution path does not include instrumented methods. In this case, an internal thread communication would incorrectly be visualized as outgoing. To overcome this problem, an entry sensor 111 may be instrumented to the communication service method 2707 after the tag extraction sensor and an exit sensor 112 may be instrumented to the end of the communication service method. This guarantees that every execution of an instrumented communication service method also provides tracing data, and that no internal thread communications are erroneously visualized as outgoing.

Some exemplary visualization forms of internal and outgoing thread communications are shown in FIGS. 32 to 34.

FIG. 32 a shows an example visualization of a monitored transaction which performed an internal thread communication in the form of a HTTP request. A frontend application 3211, which is instrumented with an agent 3203, executes a method that performs HTTP request based thread communication 3201. The communication target is a backend application 3212, with another agent 3204, and the recorded tracing data contains method invocations describing the server side handling 3202 of the performed web request.

FIG. 32 b shows an example visualization of the flow of the monitored transaction from one application to the other. First, an incoming request 3210 is registered by the client application 3211, which performs thread communication in form of HTTP requests 3213 with the backend application 3212 to generate corresponding response for the incoming request 3210.

FIG. 33 a shows transaction tracing data of a transaction that performs a thread communication with a non-instrumented server application. The transaction is executed by a frontend application 3311 which is instrumented by an agent 3302. The tracing data contains a method that performs a HTTP request based thread communication 3301, but it does not contain tracing data describing the server side handling of the thread communication (cf. 3202 in FIG. 32 a). Information about the target of the outgoing thread communication, in form of e.g. a HTTP URL is captured and visualized, see 3303.

FIG. 33 b provides a transaction flow visualization of the transaction described in FIG. 33 a, and shows that web requests 3310 are received by a frontend application 3311, and the transaction flow shows that there are some HTTP based requests triggered by the transaction execution on the frontend side. But as there is no tracing data describing the server side handling of the requests, the target of those requests is visualized as “external service” 3312. The described example only shows outgoing requests directed to an application running at the same host as the client application, which is visualized as “domainless” external service. In case a transaction performs outgoing thread to multiple, different remote hosts, this would be visualized by different “external service” nodes for each different target domain.

FIG. 34 a provides a transaction flow of a transaction that performs both internal and outgoing thread communication. Incoming web requests 3401 are received by a frontend application 3402, which initializes internal thread communications 3404 with a monitored backend application 3403, and outgoing thread communications with a not instrumented server 3408, which is visualized as “external service”. The backend application 3403 sends database queries 3406 to a data base 3407.

FIG. 34 b shows a list based description of the HTTP requests that triggered the execution described in FIG. 34 a and all HTTP requests initialized by the transaction.

The HTTP request 3414, which is visualized as sever only request (Client or Server indicator is “S” for server), is the request that triggered the execution of the transaction. Transaction 3412, which is visualized as client/server request (Client or Server indicator is “C/S” for client and server) which indicates that both client and server side transaction tracing data is available. Transaction 3413 is visualized as client only or outgoing transaction (Client or Server is “C”) which indicates that only client side tracing data is available and that the described request is outgoing. For both internal and outgoing requests, communication target information in form of a request URI 3411 is available.

It is to be understood that although the invention has been described above in terms of particular embodiments, the foregoing embodiments are provided as illustrative only, and do not limit or define the scope of the invention. Various other embodiments, including but not limited to the following, are also within the scope of the claims. For example, elements and components described herein may be further divided into additional components or joined together to form fewer components for performing the same functions.

Any of the functions disclosed herein may be implemented using means for performing those functions. Such means include, but are not limited to, any of the components disclosed herein, such as the computer-related components described below.

The techniques described above may be implemented, for example, in hardware, one or more computer programs tangibly stored on one or more computer-readable media, firmware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on (or executable by) a programmable computer including any combination of any number of the following: a processor, a storage medium readable and/or writable by the processor (including, for example, volatile and non-volatile memory and/or storage elements), an input device, and an output device. Program code may be applied to input entered using the input device to perform the functions described and to generate output using the output device.

Each computer program within the scope of the claims below may be implemented in any programming language, such as assembly language, machine language, a high-level procedural programming language, or an object-oriented programming language. The programming language may, for example, be a compiled or interpreted programming language.

Each such computer program may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. Method steps of the invention may be performed by one or more computer processors executing a program tangibly embodied on a computer-readable medium to perform functions of the invention by operating on input and generating output. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, the processor receives (reads) instructions and data from a memory (such as a read-only memory and/or a random access memory) and writes (stores) instructions and data to the memory. Storage devices suitable for tangibly embodying computer program instructions and data include, for example, all forms of non-volatile memory, such as semiconductor memory devices, including EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROMs. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits) or FPGAs (Field-Programmable Gate Arrays). A computer can generally also receive (read) programs and data from, and write (store) programs and data to, a non-transitory computer-readable storage medium such as an internal disk (not shown) or a removable disk. These elements will also be found in a conventional desktop or workstation computer as well as other computers suitable for executing computer programs implementing the methods described herein, which may be used in conjunction with any digital print engine or marking engine, display monitor, or other raster output device capable of producing color or gray scale pixels on paper, film, display screen, or other output medium.

Any data disclosed herein may be implemented, for example, in one or more data structures tangibly stored on a non-transitory computer-readable medium. Embodiments of the invention may store such data in such data structure(s) and read such data from such data structure(s). 

1. A method performed by at least one computer processor executing computer program instructions stored on at least one non-transitory computer-readable medium, the method comprising: (1) monitoring a distributed transaction executed by a monitored application to generate tracing data, wherein the tracing data includes tracing data representing a thread communication performed by the distributed transaction, wherein the thread communication comprises a thread communication message transmitted by a sender thread within the monitored transaction to a receiver thread; (2) using the tracing data to determine whether the receiver thread is within the monitored application.
 2. The method of claim 1, wherein the thread communication message comprises an HTTP request transmitted by the sender thread to the receiver thread.
 3. The method of claim 1, wherein the thread communication message comprises a web services request transmitted by the sender thread to the receiver thread.
 4. The method of claim 1, wherein the thread communication comprises a remote method invocation message transmitted by the sender thread to the receiver thread.
 5. The method of claim 1, wherein the thread communication comprises a message transmitted by the sender thread to the receiver thread using a messaging server.
 6. The method of claim 1, wherein the sender thread is executed by a first virtual machine and wherein the receiver thread is executed by a second virtual machine.
 7. The method of claim 1, wherein the sender thread is executed by a first process and wherein the receiver thread is executed by a second process.
 8. The method of claim 1: wherein (1) comprises using a first monitoring system to monitor the distributed transaction, including monitoring the sender thread; and wherein (2) comprises using the tracing data to determine whether the receiver thread is being monitored by the first monitoring system.
 9. The method of claim 8, wherein (2) comprises determining that the receiver thread is not being monitored by the first monitoring system.
 10. The method of claim 8: wherein the sender thread is executed by a client and wherein the receiver thread is executed by a server; wherein (1) comprises generating client-side tracing data representing a first portion of the thread communication, wherein the first portion of the thread communication is executed at the client; and wherein (2) comprises: (2)(a) determining whether server-side tracing data representing a second portion of the thread communication has been received from the server, wherein the second portion of the thread communication is executed at the server; (2)(b) determining that the receiver thread is within the monitored application if the server-side tracing data has been received from the server; and (2)(c) determining that the receiver thread is not within the monitored application if the server-side tracing data has not been received from the server.
 11. The method of claim 1: wherein the tracing data representing the thread communication includes state data representing a state of the thread communication.
 12. The method of claim 11, wherein the state data comprises an HTTP status code.
 13. The method of claim 11, wherein (A) comprises executing a tagging sensor to generate the state data.
 14. The method of claim 11, wherein (A) comprises executing an exit sensor to generate the state data.
 15. The method of claim 11, wherein the state data indicates whether the thread communication completed successfully.
 16. The method of claim 1: wherein the tracing data representing the thread communication includes destination data representing a destination of the thread communication.
 17. The method of claim 16, wherein the destination data comprises data representing an HTTP URL.
 18. The method of claim 16, wherein the destination data comprises data representing a remote method server name.
 19. The method of claim 16, wherein (A) comprises executing a tagging sensor to generate the destination data.
 20. The method of claim 16, wherein (A) comprises executing an entry sensor to generate the destination data.
 21. The method of claim 1, further comprising: (3) generating a visualization of the tracing data based on whether the receiver thread is determined to be within the monitored application.
 22. The method of claim 21, wherein (3) comprises: (3)(a) if the receiver thread is determined to be within the monitored application, then generating a first visualization of the tracing data; (3)(b) if the receiver thread is not determined to be within the monitored application, then generating a second visualization of the tracing data, wherein the second visualization differs from the first visualization.
 23. The method of claim 21, wherein the thread communication comprises an HTTP request.
 24. The method of claim 21, wherein the thread communication comprises a web service request.
 25. The method of claim 21, wherein the thread communication comprises a remote method call.
 26. The method of claim 21, wherein (3) comprises: (3)(a) obtaining data representing a destination of the thread communication; and (3)(b) generating the visualization of the tracing data based on the data representing the destination of the thread communication.
 27. The method of claim 26, wherein the data representing the destination of the thread communication comprises data representing an HTTP URL.
 28. The method of claim 26, wherein the data representing the destination of the thread communication comprises data representing a remote method server name.
 29. The method of claim 21, wherein (3) comprises: (3)(a) obtaining data representing a state of the thread communication; and (3)(b) generating the visualization of the tracing data based on the data representing the state of the thread communication.
 30. The method of claim 29, wherein the data representing the state of the thread communication comprises an HTTP status code.
 31. The method of claim 21, wherein (3) comprises: (3)(a) obtaining data representing a destination of the thread communication; (3)(b) obtaining data representing a state of the thread communication; and (3)(c) generating the visualization of the tracing data based on the data representing the destination of the thread communication and the data representing the state of the thread communication.
 32. A system comprising: at least one computer processor; at least one non-transitory computer-readable medium having computer program instructions stored therein, wherein the computer program instructions are executable by the at least one computer processor to perform a method, the method comprising: (1) monitoring a distributed transaction executed by a monitored application to generate tracing data, wherein the tracing data includes tracing data representing a thread communication performed by the distributed transaction, wherein the thread communication comprises a thread communication message transmitted by a sender thread within the monitored transaction to a receiver thread; (2) using the tracing data to determine whether the receiver thread is within the monitored application.
 33. The method of claim 32, wherein the thread communication message comprises an HTTP request transmitted by the sender thread to the receiver thread.
 34. The method of claim 32, wherein the thread communication message comprises a web services request transmitted by the sender thread to the receiver thread.
 35. The method of claim 32, wherein the thread communication comprises a remote method invocation message transmitted by the sender thread to the receiver thread.
 36. The method of claim 32, wherein the thread communication comprises a message transmitted by the sender thread to the receiver thread using a messaging server.
 37. The method of claim 32, wherein the sender thread is executed by a first virtual machine and wherein the receiver thread is executed by a second virtual machine.
 38. The method of claim 32, wherein the sender thread is executed by a first process and wherein the receiver thread is executed by a second process.
 39. The method of claim 32: wherein (1) comprises using a first monitoring system to monitor the distributed transaction, including monitoring the sender thread; and wherein (2) comprises using the tracing data to determine whether the receiver thread is being monitored by the first monitoring system.
 40. The method of claim 39, wherein (2) comprises determining that the receiver thread is not being monitored by the first monitoring system.
 41. The method of claim 39: wherein the sender thread is executed by a client and wherein the receiver thread is executed by a server; wherein (1) comprises generating client-side tracing data representing a first portion of the thread communication, wherein the first portion of the thread communication is executed at the client; and wherein (2) comprises: (2)(a) determining whether server-side tracing data representing a second portion of the thread communication has been received from the server, wherein the second portion of the thread communication is executed at the server; (2)(b) determining that the receiver thread is within the monitored application if the server-side tracing data has been received from the server; and (2)(c) determining that the receiver thread is not within the monitored application if the server-side tracing data has not been received from the server.
 42. The method of claim 32: wherein the tracing data representing the thread communication includes state data representing a state of the thread communication.
 43. The method of claim 42, wherein the state data comprises an HTTP status code.
 44. The method of claim 42, wherein (A) comprises executing a tagging sensor to generate the state data.
 45. The method of claim 42, wherein (A) comprises executing an exit sensor to generate the state data.
 46. The method of claim 42, wherein the state data indicates whether the thread communication completed successfully.
 47. The method of claim 32: wherein the tracing data representing the thread communication includes destination data representing a destination of the thread communication.
 48. The method of claim 47, wherein the destination data comprises data representing an HTTP URL.
 49. The method of claim 47, wherein the destination data comprises data representing a remote method server name.
 50. The method of claim 47, wherein (A) comprises executing a tagging sensor to generate the destination data.
 51. The method of claim 47, wherein (A) comprises executing an entry sensor to generate the destination data.
 52. The method of claim 32, further comprising: (3) generating a visualization of the tracing data based on whether the receiver thread is determined to be within the monitored application.
 53. The method of claim 52, wherein (3) comprises: (3)(a) if the receiver thread is determined to be within the monitored application, then generating a first visualization of the tracing data; (3)(b) if the receiver thread is not determined to be within the monitored application, then generating a second visualization of the tracing data, wherein the second visualization differs from the first visualization.
 54. The method of claim 52, wherein the thread communication comprises an HTTP request.
 55. The method of claim 52, wherein the thread communication comprises a web service request.
 56. The method of claim 52, wherein the thread communication comprises a remote method call.
 57. The method of claim 52, wherein (3) comprises: (3)(a) obtaining data representing a destination of the thread communication; and (3)(b) generating the visualization of the tracing data based on the data representing the destination of the thread communication.
 58. The method of claim 57, wherein the data representing the destination of the thread communication comprises data representing an HTTP URL.
 59. The method of claim 57, wherein the data representing the destination of the thread communication comprises data representing a remote method server name.
 60. The method of claim 52, wherein (3) comprises: (3)(a) obtaining data representing a state of the thread communication; and (3)(b) generating the visualization of the tracing data based on the data representing the state of the thread communication.
 61. The method of claim 60, wherein the data representing the state of the thread communication comprises an HTTP status code.
 62. The method of claim 52, wherein (3) comprises: (3)(a) obtaining data representing a destination of the thread communication; (3)(b) obtaining data representing a state of the thread communication; and (3)(c) generating the visualization of the tracing data based on the data representing the destination of the thread communication and the data representing the state of the thread communication. 